Method and apparatus for processing a context change request in a CCOW environment

ABSTRACT

A method and apparatus for use in a computer system comprising at least two software applications sharing context in accordance with a Clinical Context Object Workgroup (CCOW) standard, wherein a context change may be requested by a user of at least one of the at least two software applications. In response to the user requesting a change from a first context to a second context, at least one business rule is applied to at least a portion of the first context and/or to at least a portion of the second context to obtain at least one result from the application of the business rule. In response to the at least one result, at least one act is performed selected from the group consisting of: denying the request to change from the first context to the second context; requesting the user to provide information relating to the requested change; and requesting the user to affirm information relating to the requested change.

BACKGROUND OF INVENTION

The Health Insurance Portability and Accountability Act (HIPAA) protectsthe privacy rights of medical patients by providing guidelines andrequirements for access to patient information. For example, HIPAAprovides that only specific individuals may access certain informationrelated to particular patients. Caregivers, such as primary carephysicians, nurses and others, may be required by HIPAA to have aclinical affiliation with a patient in order to view the patient'sinformation. Some clinical organizations may impose additionalconstraints on access to patient information.

In some clinical settings, computer systems provide users with access toinformation related to patients. For example, patient information suchas billing, insurance and/or diagnostic information may reside inelectronic file storage (e.g., one or more databases) and be accessedusing one or more software applications. Some conventional softwareapplications provide functionality which facilitates compliance withHIPAA and/or organizational policies. For example, some softwareapplications request that a user affirm that a clinical affiliationexists between the user and the patient or specify the nature of theaffiliation, before allowing the user to view the patient's information.Thus, the user is forced to make an affirmative representation that theaccess to patient information is in compliance with HIPAA regulations,and a record may be retained for future audits.

Some computer systems which include clinical software applicationsprovide context management capability. As described in co-pendingcommonly assigned U.S. patent application Ser. No. 09/545,396, Pat. No.6,993,556, which is incorporated herein by reference, context managementcapability may be provided via a context manager which can communicatewith a plurality of software applications. The context manager mayfacilitate a sharing of context between applications, wherein thecontext may include information associated with a user, patient,clinical encounter or other information relevant to the application. Asan example, in a system having context management capability, when auser employing a first software application to view information on apatient switches to a second software application to continue workrelated to that patient, the system may retain a context whichautomatically identifies the patient and the user to the secondapplication, so that, for example, the user need not provide a user orpatient identifier to the second application to begin work. As a result,the user need not perform the time-consuming processes of logging intothe second application and providing a patient identifier to access thepatient's information. As mentioned above, a context may include anyinformation suitable for sharing between applications.

A standard known as Health Level Seven Context Management Specificationwas established by the Health Level Seven Clinical Context ObjectWorkgroup (CCOW) to define a standard for an interface and components ofa context management system architecture. The standard is referred tohereinafter as “the CCOW standard.” In accordance with the CCOWstandard, a context manager facilitates a sharing of context databetween applications, wherein context data provides information onvarious subjects, such as a user, patient, encounter, and others. When achange from one context to another is desired (e.g., when a user wishesto view information on a different patient), a context changetransaction is executed, and context data related to one or moresubjects may be updated to implement the context change. For example, ifa user desires to change the patient for which information is viewed,then a context change transaction may update the patient subject datawithin a context, but leave other context data (i.e., data on othersubjects) intact. For example, the user subject data may be left intactby this context change transaction, so that the user need not log intoother applications again to view information on the new patient.

Some context management systems allow user access to patient information(and other information) to be audited, so that compliance with HIPAA,organizational policies and/or other standards may be monitored. Forexample, a context management system having audit capability isdescribed in co-pending commonly assigned U.S. patent application Ser.No. 10/014,341, Pat. No. 6,941,313 ,which is incorporated herein byreference.

FIG. 1 illustrates an exemplary computer system including a contextmanager with audit capability, wherein context manager 130 communicateswith context-enabled applications 110 and 120 to facilitate contextsharing there between. In the system of FIG. 1, applications 110 and 120both reside on workstation 100, and both may be capable of accessingpatient information. Context manager 130 communicates with a storagefacility 150 that stores information provided by context manager 130,such as information related to context changes initiated by users ofapplications 110 and 120. Such information may include an indication ofthe user who initiated the context change, the patient whose informationthe user attempted to access, and/or the application employed by theuser to initiate the change.

Auditor 140 may extract information from storage facility 150 todetermine compliance with HIPAA, organizational policies, and/or otherstandards. For example, auditor 140 may produce reports which show thepatient records that have been accessed by certain users. Auditor 140may also be configured to produce and send an alert to an administratorif a user who is not authorized to view a particular patient's recordsattempts to access those records. Other monitoring and/or auditingfunctions may also be performed.

In certain cases, a user may not be required to have an existingclinical affiliation with a patient to be authorized to view thepatient's information. For example, a clinician may need to view apatient's records in an emergency, particularly if the patient's primarycaregiver is not available and the patient is in danger. This iscommonly referred to in the health care industry as “break the glass”access. In general, a user may break the glass to view patientinformation if the user is aware that they are not otherwise authorizedto access the patient's information, but must to do so to provide propercare for the patient. For example, a clinician may break the glass todetermine whether an unconscious patient has any known allergies beforeadministering medication to the patient.

SUMMARY OF INVENTION

One embodiment is directed to a method performed in a computer systemcomprising at least two software applications sharing context inaccordance with a Clinical Context Object Workgroup (CCOW) standard,wherein a context change may be requested by a user of at least one ofthe at least two software applications. The method comprises acts of:(A) in response to the user requesting a change from a first context toa second context, applying at least one business rule to at least aportion of the first context and/or to at least a portion of the secondcontext to obtain at least one result from the application of thebusiness rule; and (B) in response to the at least one result,performing at least one act selected from the group consisting of:denying the request to change from the first context to the secondcontext; requesting the user to provide information relating to therequested change; and requesting the user to affirm information relatingto the requested change. Another embodiment is directed to at least onecomputer-readable medium encoded with instructions which, when executed,perform the above-described method.

Yet another embodiment provides an agent for use in a computer systemcomprising at least two software applications sharing context inaccordance with a Clinical Context Object Workgroup (CCOW) standard,wherein a context change may be requested by a user of at least one ofthe at least two software applications. The agent comprises: at leastone processor programmed to, in response to the user requesting a changefrom a first context to a second context; apply at least one businessrule to at least a portion of the first context and/or to at least aportion of the second context to obtain at least one result from theapplication of the business rule; and in response to the at least oneresult, perform at least one act selected from the group consisting of:denying the request to change from the first context to the secondcontext; requesting the user to provide information relating to therequested change; and requesting the user to affirm information relatingto the requested change.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram showing a conventional context managementsystem having audit capability;

FIG. 2 is a block diagram showing one embodiment of a system having thecapability to apply one or more business rules before allowing a contextchange to complete, according to one embodiment of the invention;

FIG. 3 is a block diagram interaction between components of the systemof FIG. 2 in applying one or more business rules before allowing acontext change to complete, according to one embodiment of theinvention;

FIG. 4 is a block diagram showing interaction between components of thesystem of FIG. 2 in applying one or more business rules before allowingthe completion of a context change, according to another embodiment ofthe invention; and

FIG. 5 shows an exemplary interface which may implement one or morebusiness rules before allowing a context change to be completed.

DETAILED DESCRIPTION

As mentioned above, HIPAA protects the privacy rights of medicalpatients by providing guidelines and restrictions on who may accesstheir information, and under what circumstances. Typically, a clinicianis required to have a clinical affiliation with a patient (e.g., thepatient may be a patient of a healthcare organization which employs theclinician) to access the patient's records. Conventionally, systemswhich provide access to patient records do not prevent access by anyindividual, in part to protect the safety of the patient in an emergencysituation. For example, in an emergency situation, a caregiver having noaffiliation with the patient may wish to gain access to the patient'srecords to determine information that may be vital to providing care tothe patient in the emergency situation (e.g., whether the patient hasany allergies to certain medications, whether the patient is takingparticular medications, etc.). Thus, it is generally accepted that theuser should be able to “break the glass” to have access to a patient'srecords in an emergency situation. As a result, systems typically do notimpose an absolute prohibition on access. However, in some situations(e.g., relating to the records for a public figure), an absoluteprohibition on access may be imposed for unauthorized users.

In view of the desirability of providing break the glass access,conventional context management systems rely upon an auditor (e.g., 140in FIG. 1) to track access to patient records by users. Specifically,user access leaves behind an audit trail that can be subsequentlyexamined to determine compliance with HIPAA. Applicants have appreciatedthat while providing such an audit capability is advantageous, animproved system can be achieved by requiring users to explicitly justifytheir authorization to access data on particular patients. For example,in accordance with one embodiment of the present invention, a userseeking to access information for a particular patient may be calledupon to justify their authorization to access that patient's records,such as by explaining the user's affiliation with the patient.

Applicants have appreciated that requesting a user to justify access toa particular patient's records can provide a number of advantages.First, requesting such a justification can reduce the likelihood ofinadvertent unauthorized access, as a user will be called upon tospecifically justify the basis for the access request, thereby reducingthe likelihood that a user will accidentally (e.g., without consideringwhether or not the access is authorized) access a patient's records.Second, requesting such a justification can deter a user seekingunauthorized access, as the user will be called upon to justify theaccess, such that if the user wishes to continue, they will be forced tomake an affirmative misrepresentation. Concerns about explaining such anaffirmative misrepresentation in the event of an audit can provide asignificant deterrent effect. Third, the nature of certainjustifications can be used as a basis for triggering various levels ofaudit review. For example, if a user were to justify access by statingthat it took place during an emergency break the glass scenario, such ajustification can be highlighted by an auditing capability, so that theaccess request can be investigated to determine whether an emergencysituation truly existed that justified the break the glass access.

One embodiment of the present invention is directed to providing acapability for requesting a user to justify an access request, and isreferred to herein as an honor agent, as the request for a justificationfor access relies upon an honor system wherein the user is expected totruthfully explain the justification for the access. Applicants haveappreciated that in a computer system sharing context in accordance withthe CCOW standard, an advantageous time for requesting a user to justifyan access request is in response to a user requesting a change incontext, because a user seeking to access new patient information willrequest a change in context to identify the new patient. In addition, byrequesting a user to justify an access request in response to a requestto change context, the justification can be provided once for allapplications that share the context, rather than requiring the user tointeract individually with multiple applications to justify the accessrequest.

Thus, in accordance with one embodiment of the present invention, inresponse to a user seeking to request a context change, one or morerules or policies can be applied to examine the requested context changeto determine whether it may impact privacy concerns as discussed in moredetail below (e.g., whether a new user is named, or the user seeksaccess to information relating to a different patient), and in the eventthat a condition specified by the rule or policy is determined to existthat may impact privacy concerns, one of several actions can take place.For example, if it is determined by the rule or policy that therequested context change could result in an unauthorized access, therequested change may simply be denied. Alternatively, in order to enablea potential break the glass situation to occur, rather than denying theaccess outright, the user may be called upon to justify the nature ofthe authorization for the requested change (e.g., to explain theaffiliation with the patient identified in a new context). For example,the user may be requested to enter information that explains thejustification for the requested access, or a system may present to theuser the information that would be necessary to justify the access andrequest that the user positively affirm that the required conditions aremet if the user provides the requested information or affirmation, therequested context change can be allowed to proceed and the informationprovided or affirmed by the user can be stored in accordance with anaudit facility for later monitoring. If the user refuses to provide oraffirm the requested information, the requested context change caneither be denied, or the user's refusal can be recorded by an auditfacility and highlighted thereby for subsequent investigation.

While one specific embodiment of the present invention described hereinrelates to the application of a business rule or policy to a requestedcontext change to implement an honor facility as mentioned above anddescribed in more detail below, it should be appreciated that thepresent invention is not limited in this respect, and that thetechniques described herein which apply a business rule to a requestedcontext change, and then either deny the request or request that theuser provide or affirm information relating to the requested change, canbe used to employ any desired functionality. In this respect, the termbusiness rule or business policy is used herein with respect tonon-environmental factors, including any criterion that relates to thebehavior of users and the way they interact with the context sharingapplication programs. The term environmental factors is used herein torefer to technology-based circumstances that may result in a requestedcontext change failing to occur, and may include timeouts and failuresof a hardware or software component to function properly. Suchcircumstances do not relate to defining a business rule or policy thatspecifies behavior relating to the way in which people interact with thecontext sharing applications. Thus, the aspects of the present inventiondescribed herein can be used in connection with any business rule orpolicy (which terms are used interchangeably herein) and is not limitedto the specific honor requests discussed in detail below.

It should be appreciated that in one embodiment of the presentinvention, the application of a business rule to a requested contextchange can lead to a result, and that one or more acts can then beperformed in response to that result. As one example, in response to arequested context change in which a user seeks access to information fora new patient, a business rule may be applied that reaches adetermination as to whether an affiliation between the user and thepatient has previously been established. If the result of theapplication of the business rule is a determination that an affiliationhas previously been established, the action performed in response tothat result may be to simply allow the requested context change toproceed. Conversely, if the result of the application of the businessrule is a determination that no affiliation has previously beenestablished, the action that may be performed in response to that resultmay be to deny the request or to request that the user provide or affirminformation describing the affiliation. This is merely one example of atype of business rule that can be applied, as well as the type ofactions that can be taken in response to a result of the business rule,as the invention is not limited in this respect. Any desired businessrule may be applied, and any desired action may be taken in response toa result of the application of the business rule.

It should be appreciated that the aspects of the present inventiondescribed herein are not limited to the application of a business rulethat results in requesting or gathering information from the user as thefinal action, as the business rule may take further actions dependingupon the information provided or affirmed by the user. For example,referring to the example above wherein a user is requested to provide oraffirm an affiliation with a patient in response to a request to changecontext to access the patient's information, a business rule can beapplied that takes different actions depending upon the response of theuser. For example, if the user fails to provide or affirm the desiredinformation, an action can be taken that prevents the context changefrom completing successfully, whereas any of various different actions(e.g., allowing the context change to complete successfully, storinginformation gathered from the user, adding information gathered from theuser into the context, etc.) can be performed when the user provides oraffirms the requested information. Thus, aspects of the presentinvention described herein contemplate the application of one or morebusiness rules in response to the request from a user to change context,including the possibility of gathering information from the user one ormore times and taking various actions in response to the resultsobtained by the application of the business rule(s).

In connection with the embodiment that relates to sharing context in aCCOW environment, it should be appreciated that the CCOW standardprovides no facility for one application program (or other softwareentity) to stop an application requesting a context change fromexecuting the change based on a business rule or policy, as anotherapplication could only indirectly cause a requested context change tonot complete by failing to communicate properly, which would constitutean environmental factor rather than a business rule or policy. Inaddition, for the aspect of the present invention that requests that theuser provide or affirm additional information in response to a requestedcontext change, the requested information can be information that is inaddition to the information defined by the CCOW standard for the sharingof a context.

While one embodiment of the present invention described in detail belowrelates to context sharing specifically in accordance with the CCOWstandard, it should be appreciated that the aspects of the presentinvention described herein are not limited in this respect, and can beemployed in any context sharing system, including those that do notcomply with the CCOW standard.

In accordance with one embodiment of the present invention thatimplements an honor agent for responding to requests to change context,a storage facility may store information relating to the business ruleapplied so that if a user had previously provided information justifyinga particular access request such as the one inherent in a requestedcontext change, the honor facility can rely upon the user's priorrepresentation, and not request information again from the user. Forexample, if a user had previously specified an affiliation with aparticular patient, that representation can be relied upon for futureattempts to access the patient information. In accordance with oneembodiment of the present invention, a suitable time limit can beimposed so that the information previously provided or affirmed by theuser can be relied upon only for that suitable time period, after theexpiration of which the user may be requested to provide or affirm theinformation anew. Of course, it should be appreciated that all aspectsof the present invention are not limited to the use of such a timeperiod or even to having the honor facility rely upon priorrepresentations in any respect.

In accordance with one embodiment of the present invention, the mannerin which a user may justify access to particular patient data can bespecified in any suitable manner (e.g., by specifying a relationshipbetween the user and the patient, between a facility with which the useris associated and the patient, or any other suitable manner) as thepresent invention is not limited in this respect.

In accordance with one embodiment of the present invention, the natureof the access provided by applications sharing a context can varydepending upon the nature of the authorization that the user specifies.For example, if a user specifies an affiliation with the patient thatderives from a consulting relationship, the user may have somewhatlimited access to the patient's information, whereas if the userspecifies a break the glass emergency access request, all of thepatient's records may be made available. It should be appreciated thatthis is merely an example, and that the manner in which the applicationscustomize the information made available to the user based upon thespecified justification for access can be done in any suitable way. Inaddition, it should be appreciated that the present invention is notlimited to use with systems wherein the nature of the information madeaccessible is customized based upon the specified access justification.

An illustrative implementation of a computer system that includes acontext manager to manage context among multiple applications andfurther includes an honor agent to implement the above-described honortechniques in accordance with one embodiment of the present invention isillustrated in FIG. 2. The system of FIG. 2 is similar in many respectsto the system of FIG. 1, and includes a workstation 100 havingapplication programs 110 and 120 executing thereon, as well as a contextmanager 130 that facilitates the sharing of context between theapplications 110 and 120, as well as an auditor 140 and storage facility150 that perform functions similar to those discussed above inconnection with FIG. 1. In one embodiment, the context manager 130 canbe provided on a server that is separate from the workstation 100 andcan communicate with the workstation 100 over any suitable communicationmedium, including a private or public network. The auditor 140 can beprovided on a same server as the context manager 130 or on any othercomputing device that can be connected to the context manager over anysuitable communication medium, including a private or public network.However, it should be appreciated that the aspects of the presentinvention described herein are not limited to this or any particularconfiguration, and that the functional components shown in FIG. 2 can bedisposed on the same or different computing devices in any suitablearrangement. In addition, it should be appreciated that each of thefunctional components described herein can be implemented as thecomponent executing on a single computer, or can be distributed amongmultiple computers.

In the embodiment illustrated in FIG. 2, the honor agent 160 is shown asinstalled on the same workstation 100 as the context sharingapplications 110, 120. As with the other functional components shown inFIG. 2, the honor agent can be implemented in its entirety on theworkstation 100, or can be arranged in other ways. For example, asdiscussed further below, in accordance with one embodiment of thepresent invention, the honor agent 160 provides a user interface to auser of the workstation 100 for accessing the applications 110 and 120,so that a module of the honor agent that implements a user interface canbe resident on the workstation 100. However, it should be appreciatedthat other modules of the honor agent can be disposed upon othercomputing devices and interact with a user interface component in anysuitable manner. For example, other modules of the honor agent 160 canexecute on a same computer as the context manager 130, or on any othersuitable computing device.

It should be appreciated that the application programs 110, 120 can takeany form, including application programs that are executed entirely onthe workstation or desktop 100, or application programs that have a userinterface executing thereon but that interact with components of theapplication program executing remotely. Examples of different types ofapplications that may share context are described in co-pending U.S.patent application Ser. No. 10/632,673, which is incorporated herein byreference. For example, applications 110, 120 may include applicationswhich execute on a web server, with the user interface on theworkstation 100 being a browser and/or applications executed on a remoteserver and emulated on workstation 100 (e.g., using the Citrix MetaFrameand ICA client architecture). These are merely examples, as the aspectsof the present invention described herein can be employed with anyapplications capable of sharing context.

In accordance with one embodiment of the present invention, by includingat least a component of the honor agent 160 on the same workstation 100or desktop as the applications that share a context, the honor agent hasthe ability to interact with the applications 110, 120 in a manner thatprevents the actions of the honor agent from being bypassed when one ofthe applications 110, 120 seeks to change context. This can be done inany of numerous ways, examples of which are discussed below, and caninclude the honor agent 160 taking control of the user interface of theworkstation 100 so that requirements imposed by the honor agent cannotbe bypassed.

In the embodiment shown in FIG. 2, the honor agent 160 communicates withthe context manager 130. This communication can be performed over anysuitable communication medium, as the present invention is not limitedin this respect. In accordance with one embodiment of the presentinvention, the honor agent 160 may communicate with the context manager130 over a private or public network. It should be appreciated thatpublic networks often have security techniques (e.g., firewalls) thatcan make it difficult for components in different security zones (e.g.,on opposite sides of a firewall) from directly communicating. Inco-pending U.S. patent application Ser. No. 10/632,673, techniques aredescribed to facilitate communication between the components of acontext sharing system in such a network environment. In accordance withone embodiment of the present invention, similar techniques can beemployed to facilitate communication between the honor agent 160 and thecontext manager 130, including through the use of a TCP/IP back channel,which is a durable connection that can be established and maintainedbetween the honor agent 160 and the context manager 130 so that thecontext manager 130 will have the capability of transmittingcommunication directly to the honor agent 160 when desired (e.g., whenthe context manger 130 detects that one of the applications 110, 120 isseeking to change context, so that the honor agent 160 may want toinject itself into that request). It should be appreciated that use of aback channel as described in the above-referenced copending applicationis merely one technique for facilitating communication between the honoragent 160 and the context manager in a network environment, and that thepresent invention is not limited to this or any other specifictechnique, as any suitable technique for facilitating communication canbe employed.

In accordance with one embodiment of the present invention, the honoragent 160 has access to a storage facility which stores informationrelated to the business rules that will be applied in response to arequested context change, as well as data that may be used by the honoragent 160 in determining whether to apply those rules in certaincircumstances and to guide the application of those rules in the mannerdescribed herein. The storage facility can be provided in any suitablelocation, as the aspects of the present invention described herein arenot limited in this respect. In the embodiment shown in FIG. 2, the dataand information used by the honor agent 160 is stored in the samestorage facility 150 that stores information relating to user accessesto patient information that is audited by the auditor 140. For example,the information and data used by the honor agent 160 may be stored in adatabase that is co-resident with a database used by the context manager130 and auditor 140 to store the audit log. However, it should beappreciated that the invention is not limited in this respect, and thatthe data and information used by the honor agent can be stored elsewhereand in any suitable form.

It should be appreciated that in some embodiments, the data andinformation used by the honor agent 160 may be stored on a differentcomputer that can be accessed using any suitable communication medium,including a private or public network. As discussed above, publicnetworks can impose security techniques that provide obstacles to directcommunication between some components in different security zones (e.g.,on opposite sides of a firewall). When the honor agent 160 (or thecomponent thereof that accesses the storage facility 150 when the honoragent is distributed and has a user interface component on theworkstation 100 but other components elsewhere) is disposed in adifferent security zone than the storage facility 150, techniques can beemployed to facilitate communication between the honor agent 160 and thestorage facility 150, including any of those techniques described aboveor any other suitable technique, as the present invention is not limitedin this respect.

Referring first to FIG. 3, as shown by arrow 300, the user 50 employsone of the applications (the application 110 in FIG. 3) to initiate acontext change. For example, the user may, via application 110, seek toaccess to a particular patient's data. In response, as shown by arrow305, the application 110 may notify the context manager 130 of therequest context change. In systems which comply with the CCOW standard,this may be accomplished via the creation of a context changetransaction by application 110, and transmission of the context changetransaction to context manager 130 for execution.

The honor agent 160 may access information (e.g., stored in storagefacility 150) related to the application of business rules to determinethe action(s) to take in response to the requested content change. Inthe description below, the data set accessed by the honor agent will bereferred to as the honor agent (HA) data set. The HA dataset may bepopulated in any suitable way. For example, in accordance with oneembodiment of the present invention, the HA data set may be pre-loadedto provide information relating to an affiliation between users andfacilities, between users and patients, and/or between facilities andpatients. Alternatively, or in addition, the HA data set may bepopulated incrementally, as users of the context management system seekto change context, and are requested by the honor agent to provideand/or affirm information relating to their authorization to accesspatient data in the manner discussed above. For example, the first timea particular user seeks to access a particular patient whose data hasnot been previously accessed, the honor agent 160 may detect thatneither the user or the patient has an affiliation stored in the HA dataset and the user may be prompted to provide desired information, such asthe facilities with which the patient is affiliated, the facilities withwhich the user is affiliated, along with justification for the requestedaccess as discussed above. This information may then be stored in the HAdata set for future use. While the embodiments of the present inventiondescribed herein are not limited in this respect, an example of futureuse can include the honor agent not going through the process ofrequesting that a user seeking a context change to access a particularpatient's data justify the access request if the HA data set alreadyindicates the nature of the affiliation between the patient and theuser.

In accordance with one embodiment of the present invention, informationrelating to an affiliation (e.g., user to patient, user to facility,facility to patient) may include temporal information related to theaffiliation. The temporal information can take any of numerous forms. Inaccordance with one embodiment of the present invention, temporalinformation is designed to provide for an expiration ofpreviously-established affiliations. In this respect, in accordance withone embodiment of the present invention, after an affiliation isspecified, the honor agent will rely upon a previously specifiedaffiliation and will not request that a user seeking to change contextto access data on a patient to which an affiliation has already beenestablished to re-assert the justification for the access request. Inaccordance with one embodiment of the present invention, the honoragent's reliance on a previously-established affiliation can include atimeout facility, such that a previously-established affiliation(including any of the types of affiliations discussed above) can belimited in time. Temporal information stored in the HA data set tosupport imposing a timeout restriction on a previously-establishedaffiliation can take any suitable form, as the present invention is notlimited in this respect. For example, when an affiliation isestablished, temporal information may be stored which reflects thecurrent time, and the honor agent can apply any appropriate rule inresponse to a subsequent access request to determine whether theaffiliation may still be relied upon, or whether a timeout situation hasoccurred wherein the information is stale and the user should berequested to explicitly re-state a justification for the requestedaccess. The time at which an affiliation will expire may be determinedat the time an access request is made, at the time affiliationinformation is provided by a user, or in any other suitable manner. Inone embodiment, the timeout or expiration time can be stored in the HAdata set. The expiration time can be a function of any suitable businessrule, and can be a set time for all affiliations, can vary by user,facility, patient, the nature of the requested access or any othersuitable criterion, as the present invention is not limited in thisrespect.

As discussed above, in accordance with one embodiment of the presentinvention, when one of the context sharing application programs seeks tochange the context, the context manager 130 will be made aware of thechange request, and will notify the honor agent 160. In accordance withthe embodiment of the present invention that allows for the use ofstored affiliations to authorize access rather than requesting accessauthorization justification from the user for each requested change, thehonor agent 160 may access the HA data set to obtain informationrelating to the affiliation or affiliations relevant to the appropriatebusiness rule that the honor agent will apply to the requestedtransaction. In accordance with the embodiment that employs a timeoutcapability for previously-established affiliations, the honor agent 160will also access the timeout information. If a valid non-expiredaffiliation has already been established, the honor agent 160 mayauthorize the context manager 130 to allow the context changetransaction to proceed unimpeded. Alternatively, if an appropriateaffiliation has not previously been established, or apreviously-established affiliation is no longer valid based upon timeconstraints, the honor agent 160 may act to request information beprovided and/or affirmed by the user in any of the ways describedherein.

It should be appreciated that the above-described data flow between thecontext sharing applications 110, 120, the context manager 130 and thehonor agent 160 are merely exemplary, as the present invention is notlimited to any particular technique, and can be implemented in anysuitable manner.

As discussed above, in accordance with one embodiment of the presentinvention, in response to a request to change context, the honor agentmay take action to prevent the requested change from completingsuccessfully unless and until the user has provided and/or affirmedrequested information. In accordance with one embodiment of the presentinvention, a dialogue box such as that shown, for example, in FIG. 5, ispresented that forces the user to respond and is incapable of beingbypassed, so that the requested context change will not completesuccessfully unless and until the information requested by the dialoguebox has been provided. As discussed above, when the user provides oraffirms requested information, the honor agent 160 may update the HAdata set with the information for future reference.

There are numerous way in which the honor agent can interact with thecontext sharing system to prevent a requested context change fromcompleting successfully if a user fails to provide or affirm requestedinformation, and the present invention is not limited to any particularimplementation techniques. Two examples are described below, one inwhich the requested context change is aborted, and another in whichactions taken in an attempt to implement the requested context changeare allowed to occur, but compensating actions are taken to undo thecontext change when the user fails to provide or affirm the requestedinformation. In accordance with the latter embodiment, the honor agenttakes action to block the user interface (e.g., by presenting thedialogue box as discussed above) so that even if actions relating to therequested context change have been implemented, the user is unable tosee any patient data resulting therefrom unless and until the honoragent determines that the user has provided or affirmed the requestedinformation. Of course, the aspect of the present invention that relatesto blocking the user interface is not limited in this respect, and canbe used in any suitable circumstance, including in connection with theembodiment which aborts a requested context change.

As discussed above, one embodiment of the present invention employs atechnique wherein the honor agent does not prevent actions fromoccurring that actually attempt to implement a requested context change,but takes action (by employing a blocking dialogue box) to prevent theuser from seeing the results of any context change until the user hasprovided or affirmed the requested information, and if the user fails todo so, by taking action that compensates for any of those taken in anattempt to implement the requested context change. In accordance withthis embodiment of the present invention, the honor agent can act asanother participant in a context, and can communicate in accordance withany protocol previously established for sharing context. An example ofsuch an implementation is described below in connection with FIG. 4specifically for use in a context sharing system that implements theCCOW standard, but it should be appreciated that the present inventionis not limited in this respect, and that similar techniques can beemployed in any context sharing system. In accordance with anotherembodiment of the present invention, the honor agent may hook into thecontext management system to prevent actions that are performed in theimplementation of a context changed to abort the requested change. Inaccordance with this embodiment of the present invention, some changesto the context management system (e.g., actions taken by the contextmanager) can be implemented to facilitate the functionality performed bythe honor agent. An example of this implementation will now be describedin connection with FIG. 3 specifically in a context management systemacting in accordance with the CCOW standard. However, it should beappreciated that this aspect of the present invention is not limited touse with a context management system operating in accordance with a theCCOW standard, and can be employed in any context management system.

In response to receipt of the notification of the requested contextchange, the context manager 130 takes a pair of actions indicated byarrows 310A and 310B, which can be performed simultaneously or in anyorder. Specifically, as noted at 310A, the context manager notifies thehonor agent 160 that a context change has been requested, so that thehonor agent can take appropriate action in any of the ways describedherein. In addition, the context manager continues with the processingof the request for the context change in the manner established by thecontext management system. When the context management system complieswith the CCOW standard, the communication from the context manager 130to the application 120 involves a polling operation to determine whetherall applications that share a context with application 110 are amenableto the proposed context change. It should be appreciated that thecompletion of a context change in a context management system inaccordance with the CCOW standard can include a number of other types ofcommunication between the applications 110, 120 and the context manager,examples of which are described in co-pending U.S. patent applicationSer. No. 10/632,673, but will not be described herein or illustrated bycommunication arrows in FIG. 3 for purposes of clarity. For purposes ofthis description, it is sufficient to note that such communications maytake place, terminating with a notification to the applications 110, 120that the context has been changed. Such final communication isillustrated conceptually in FIG. 3 with the dotted lines 360A, 360B,which indicate a communication from the context manager 130 to theapplications 110, 120. Of course, it should be appreciated that acommunication indicating that the context change has been completed maytake forms other than communication from the context manager 130 to theapplications 110, 120, as the aspects of the present invention describedherein are not limited to any particular implementation.

As discussed above, the context manager 130, application programs 110,120 and honor agent 160 may be implemented on different computers thatmay communicate via any communication medium, including one or morenetworks that include security facilities that place these components indifferent security zones, including an implementation wherein componentsof the honor agent 160 are installed in a distributed manner such thatportions of the honor agent other than the user interface may reside onother devices than the workstation 100. As mentioned above, any suitabletechnique for facilitating communication between components in differentsecurity zones (including the use of back channel communicationtechniques) may be employed, as the present invention is not limited inthis respect.

In response to receipt of the notification at 310A of the requestedcontext change, the honor agent 160 applies a business rule to therequested context change to determine what, if any, actions to take inresponse thereto. As discussed above, the application of the businessrule can include the execution of any suitable instructions, includingaccessing the HA dataset (e.g., stored in the storage facility 150),information relating to the new or existing context, or any othersuitable information, as the aspects of the present invention describedherein are not limited in any respect in terms of the nature of thebusiness rule applied, or the information used in applying the rule.

Referring to the example described above wherein the honor agentresponds to a request for a context change by applying a business rulethat requires the user to provide or affirm information (e.g., anaffiliation of the user with a new patient) before allowing the contextchange to complete successfully, the business rule executed by the honoragent 160 may be defined by instructions stored in any suitable location(e.g., in the HA dataset or elsewhere) and can include examininginformation stored in the HA dataset (e.g., when the user has apreviously-established affiliation with the new patient that has notexpired) as well as information contained in the new context (e.g., thepatient identified for the context switch). The accessing of informationfrom the HA dataset, which may be in the storage facility 150 in FIG. 3as discussed above, is illustrated conceptually by the communicationarrow 320 in FIG. 3.

As discussed above, as a result of application of the business rule, thehonor agent 160 may determine that the requested context change shouldproceed unimpeded (e.g., if the information in the HA dataset indicatesthat the user has a valid unexpired affiliation with the new patient) ormay require that the user provide an affirmative representation relatingto a justification for the requested context change before proceeding.As further discussed above, when the latter situation arises, the honoragent may present a user interface to the user to gather the desiredinformation. This is shown conceptually in FIG. 3, via the interface 165that is made available to the user via an action 325 of the honor agent.The interface 165 can take any suitable form, as the aspects of thepresent invention described herein are not limited in this respect. Anexemplary interface 165 is shown in FIG. 5 and will be described infurther detail below. This interface of FIG. 5 is provided forillustrative purposes only, as an interface may take any of numerousforms.

As discussed above, if the user fails to provide or affirm theinformation presented by the user interface, the honor agent may refuseto allow the requested context change to complete successfully. Asdiscussed above, in connection with the embodiment of FIG. 3, theapplication programs 110, 120 and the context manager 130 can, inparallel with the honor agent applying the desired business rules, takethe actions normally specified by the context management system torespond to the requested context change, and may complete those actionsin a manner that would normally result in successful completion of thecontext change. However, as discussed above, the interface 165 can bepresented as a dialogue box on the workstation 100 so that user 150 willnot have access to any information resulting from the requested contextchange.

In addition, honor agent 160 can take any desired action to compensatefor the actions taken in attempting to complete the requested contextchange, so that the requested change ultimately does not completesuccessfully. The nature of the compensating actions may vary dependingupon the nature of the context management system and can take any form,as the aspects of the present invention described here are not limitedin this respect. In accordance with one aspect of the embodiment of thepresent invention, the honor agent 160 can inform the context manager130 (in a communication labeled 340 in FIG. 3) that compensating actionsfor the requested context change should be executed, and the contextmanager, via communications with the application programs 110 and 120can perform such compensating actions.

The user may respond (as shown conceptually by the dotted line 330 inFIG. 3) to the information requested by the honor agent interface 165 inany suitable manner. For example, the user may input information by akeyboard, voice recognition system, mouse clicks, touch screen, or anyother technique, as the present invention is not limited in thisrespect. When the user provides the desired information via theinterface 165, the information is passed (as shown conceptually at 335in FIG. 3) to the honor agent 160 so that the honor agent may takesuitable action. For example, the honor agent may simply remove theinterface 165 so that the user has access to the applications 110, 120that have completed the context change, the honor agent may inform thecontext manager 130 that the context change can proceed to successfulcompletion and/or the honor agent may store in the HA datasetinformation recording the information provided or affirmed by the user50. Any such information recorded in the HA dataset may, in accordancewith one embodiment of the present invention, be made available to anaudit capability, such as the auditor 140, as shown conceptually witharrow 355 in FIG. 3.

As discussed above, the information stored in the HA dataset and madeavailable to an auditing facility may take any form, as the presentinvention is not limited in this respect. As discussed above, the auditfacility may be capable of auditing information based on any of numerouscriteria, including information recording the justification that a userprovided for accessing particular patient data. For example, the auditormay prepare reports and be particularly sensitive to users thatspecified a break the glass emergency situation to justify access to aparticular patient record, or based on any other suitable criteria, asthe present invention is not limited in this respect.

In accordance with one embodiment of the present invention, the honoragent may take the further action of inserting data into a contextinformation that relates to the information provided or affirmed by theuser in justifying the requested context change. For example, the honoragent can add data to the context information relating to any of thetypes of affiliations discussed above, including an affiliation betweenthe user and patient, the user and a health care facility, and/or ahealth care facility and the patient. Such data can be added in anysuitable way, as the present invention is not limited in this respect.In one illustrative example for use in a context management system thatoperates in accordance with the CCOW standard, a new subject can becreated that is of an identifier type, as it identifies a patient recordaccess event. The subject may be dependent upon the patient subject, ormay be implemented as an independent subject. The types of informationthat may be provided in the new subject can include, as discussed above,a user affiliation, a patient affiliation, and/or the justification thata user gave for seeking access to the patient data at a particular pointin time.

In accordance with one embodiment of the present invention, one or moreof the applications 110, 120 may be configured to recognize theinformation provided or affirmed by the user to justify a context change(e.g., when the data is added to the context it may become visible tothe application programs 110, 120) and to change the behavior and/orfunctionality based thereupon. For example, in accordance with oneembodiment of the present invention, when an emergency or break theglass access request is specified by the user, one or more of theapplication programs 110, 120 may be configured to facilitate access toall patient information to facilitate an emergency response. It shouldbe appreciated that this is simply one example of the ways in which thecontext of sharing applications can respond to information provided oraffirmed by the user in requesting a context change, as numerous otherexamples are possible, as the aspect of the present invention directedto this modified behavior and/or functionality of the context sharingapplication is not limited in this respect.

As discussed above, one aspect of the technique for preventingsuccessful completion of a requested context change without the userproviding or affirming the information is that it can be employed as asupplement to an existing context management system, without requiringhooking into or modifying the context management system. Some contextmanagement systems may have communication timeouts built into theirarchitecture, including both message-level timeouts (e.g., those thatrelate to communications from one component of the system to another)and transaction level timeouts that bracket various phases of a contextchanged transaction. In accordance with one embodiment of the presentinvention, techniques are employed for dealing with potentialcommunication timeouts provided by a context management system whileseeking to ensure that no access request goes unaudited and that auser-friendly environment is maintained. While advantageous, it shouldbe appreciated that the present invention is not limited in thisrespect, and that a context management system include alternativelybeing modified so that timeout issues may not be dealt with and/or thetechnique described herein can be employed with a context managementsystem that does not employ communication timeouts.

In a first embodiment for dealing with a timeout situation, the honoragent 160 may present the interface 165 (e.g., the dialog as discussedabove) for a period of time less than the timeout period established bythe context management system for performing the context managementsystem activities relating to processing the request for a change incontext. For example, if the context management timeout period is tenseconds, the honor agent 160 may present the interface 165 for sevenseconds, to ensure that the user need respond to the honor agent beforethe expiration of the context management timeout. If the user does notrespond to the honor agent interface 165 during the specified timeoutperiod, the honor agent interface 165 may be removed and the requestedcontext change can be prevented from completing successfully (e.g., bycompensating for any actions taken or aborting the requested contextchange). Thus, in order to execute a context change to see a new patientdata, the user will need to select the patient again.

In an alternative approach, the honor agent may employ the interface 165to block the user from seeing any new patient data that results from arequested context change in the manner discussed above, and provides itsown timeout feature for the interface 165 that can be any length oftime, including a length of time longer than the timeouts established bythe context management system. This approach can be employed when aresponse from the honor agent 160 verifying that a requested contextchange is authorized is employed by the context management system, suchthat the context management system may proceed as if the honor agentwere not present and complete a requested context change in its typicalmanner, such that timeout issues within the context management systemare of no concern. Since the interface 165 will prevent the user fromseeing any new patient data resulting from a requested context change,unaudited access to the new data is prevented, and any desired timeoutperiod (including no timeout at all) can be applied to the maintenanceof the interface 165 by the honor agent.

As discussed above, in accordance with one embodiment of the presentinvention, a requested context change can be prevented from completingsuccessfully if the user does not provide or affirm informationrequested by the honor agent by either aborting the requested contextchange or taking compensating actions. In accordance with one embodimentof the present invention, compensating actions can include the honoragent initiating a context change operation to change the context backto the context that existed before the user requested the change thatwas ultimately prevented from completing successfully. It should beappreciated from the foregoing that it is possible that the compensatingcontext change can timeout. To address such a concern, in accordancewith one embodiment of the present invention, when the context managersees a request from the honor agent to change context, it canimmediately switch the patient context to an empty context, so that ifthe compensating request for a context change timesout, the user is notgiven access to any patient data, thereby preventing the user fromaccessing the patient data the user sought to access but was preventedfrom accessing by the honor agent.

As discussed above, in an alternate embodiment of the invention, ratherthan preventing a requested context change from completing successfullyby performing compensating actions, one embodiment of the presentinvention is directed to a technique that aborts a requested contextchange if a user fails to provide or affirm the information requested bythe honor agent. This aspect of the present invention can be implementedin any suitable manner, as the invention is not limited to anyparticular implementation technique. In accordance with one embodimentof the present invention, techniques can be employed that hook into thecontext management system and prevent the completion of actions employedthereby to implement a context change. These communications can includecommunications between the context sharing applications 110, 120 and thecontext manager 130, or any communications that, when blocked, willprevent the completion of a context change, as the present invention isnot limited in this respect.

One illustrative implementation of the embodiment of present inventionthat aborts requested context change will now be described referring toFIG. 4, wherein context sharing may be implemented in accordance withCCOW standards. Initially, a user 50 of application program 110 requestsa change in context, for example to access data for a new patient. Asshown at 405, the application program 110 may notify the context manager130 of the requested context change. Rather than simply taking thenormal action of querying the other applications sharing context as towhether the requested change is acceptable, the context manager (asshown at 410) can inform the honor agent 160 of the requested contextchange, and wait a response from the honor agent 160 before proceeding.The honor agent may (as illustrated at 430) provide an interface 165 tothe user, requesting the user (at 435) provide or affirm informationjustifying the context change, which can then be relayed to the honoragent 160 (illustrated at 440). The honor agent 160 may present the userinterface 165 in much the same manner as discussed above. However,because the embodiment described in connection with FIG. 4 prevents arequested context change from completing, there is no concern that theuser will gain unaudited access to the new patient data on the displayscreen, so that the interface 165 need not block the display ofinformation presented by the context sharing applications, although suchan implementation in this embodiment is of course possible.

The manner in which the honor agent applies a business rule to therequested context change, based potentially on information stored in theHA dataset (e.g., stored in the storage facility 150), information ineither the old or new context, or any other information can be performedin much the same manner as discussed above. For example, communicationbetween honor agent 160 and storage facility 150 may occur as indicatedat 315 and 320, as described above with reference to FIG. 3.

When the user provides or affirms information via the interface 165required by the honor agent 160, the honor agent may inform the contextmanager (as shown at 445) that the requested context change can proceed,at which point the context manager 130 may implement the context changein the usual way. As discussed above, in accordance with one embodimentof the present invention, information provided or affirmed by the usermay be added to the context (as well as potentially being stored in theHA dataset), such that this information can be provided by the honoragent 160 to the context manager or any other suitable component in muchthe same manner as discussed above.

When the user fails to provide or affirm the information required by thehonor agent 160, the honor agent may inform the context manager 130(illustrated at 445) that the requested context change is denied, suchthat the context manager 130 can then abort the requested context changein any suitable manner (e.g., by informing the user 50 via therequesting application 110 that the requested context change has beendenied).

Again, the above-described example is provided merely for illustrativepurposes, as the aspect of the present invention that aborts requestedcontext changes in the absence of a user providing or affirminginformation can be implemented in any of numerous ways, and is notlimited to this specific example discussed above or to use with acontext management system operating in accordance with the seek howstandard.

As discussed above, the interface 165 presented by the honor agent cantake any of numerous forms, as the present invention is not limited toany particular interface, either in terms of the technical manner inwhich information is exchanged with the user, the content of theinformation that the user is asked to provide and/or affirm, or theconfiguration of the interface. An exemplary interface 165 isillustrated in FIG. 5. The interface 165 includes warning text 505 thatmay be customized for each installation, and that provides a warning tothe user that they are expected to provide the information truthfully,and that their response may be audited.

In the embodiments shown, interface 165 also includes portions 510 and515, which request the user to specify affiliations for the user andpatient, respectively. In one embodiment, the portions 510 and 515 maybe drop-down boxes that are populated with options from which the usermay select. However, these portions can be implemented in any suitableway, including through the use of fields requiring that the user enterinformation describing the specified affiliations.

The illustrative interface shown in FIG. 5 further includes a portion520 that requested that the user specify a reason for the patient recordaccess. As with the portions 510 and 515, the portion 520 can beimplemented as a drop-down box which represents options from which theuser can select, or may take any other form, including a field in whicha user can provide information specifying the reason for the access.

The interface 165 illustrated in FIG. 5 further includes a continue box525 that a user can select (e.g., with a mouse click) after providinginformation for the other fields to submit the information forprocessing by the honor agent, as well as a cancel field 530 that a usercan select to cancel the requested context change. For example, a userthat sought unauthorized access to patient information accidentally maybe alerted to such a fact to the presentation of the interface 165 andmay choose to cancel their request.

Finally, the illustrative interface shown in FIG. 5 includes the “breakthe glass” field 535 that can enable emergency access in the mannerdiscussed above. It should be appreciated that “break the glass” accesscan alternatively be provided as one of the access reasons to choose. Infield 520, but that the separate field 535 can optionally be provided tofacilitate quick user access in the event of an emergency.

It should be appreciated that in some cases, no affiliations maypreviously have been stored for either a user or a patient. In such acircumstance, the user interface 165 can provide the capability for auser to enter affiliations for the user and/or patient.

As discussed above, the aspects of the present invention describedherein that relate to implementing an honor system that requests a userto justify an attempted access request and response to a context changeare not limited to use with a CCOW system, and can be employed inconnection with any context management system.

In addition, the aspects of the present invention described herein arenot limited to use with implementing an honor facility, as an agent orother component in a context management system may respond to a requestfor a context change by applying any suitable business rule, and bytaking any suitable action, such that the aspects of the presentinvention are not limited to taking an action that denies a requestedcontext change. For example, aspects of the present invention can applybusiness rules that request that information be provided or affirmedrelating to a requested context change, and/or can involve thegeneration of one or more alerts or the adding into the context ofadditional information. Numerous other uses are possible. For example,in response to a request from a user to change context to access recordsfor a patient, the business rule may apply that accesses records of thepatient and presents the user with information relevant thereto, such aswhether the patient is insured, if so, the identity of the insurancecompany, notifying the user of potential passed payment problems, etc.,and may then ask the user whether they wish to continue.

As another example, in response to a request for a context change toaccess a particular system, the agent may query the user on whether theuser has been trained on a new system, and may or may not choose to denyaccess if the user does not specify that they have been trained on thenew system.

As a further example, in a response to a request to change context to anew patient, relevant information about the patient may be highlightedto the user, such as notifying the user of particular allergies or othersignificant health aspects of the patient.

Again, the above examples are merely illustrative, as the presentinvention is not limited in this respect. In this respect, the aspectsof the present invention can relate to an agent that, in response to arequest of context change, can provide an interface to the user basedupon any suitable business rule, with the business rule being based uponany suitable factors, such as, stored information relating to the user,the patient, or any other aspect of the context, based upon informationin either the new or used context, or any other suitable factor. Theinterface presented by the agent may regulate access to the informationin the context, including a complete denial of access in situations thatdo not impact health issues necessitating a “break the glass” emergencytype of scenario. In addition, the interface can request any desiredinformation from the user, or can alert the user to information of whichthe user should be cognizant, and optionally require the user toacknowledge or affirm.

As should be appreciated from the foregoing, one embodiment of theinvention is directed to use in a computer system comprising two or moresoftware applications that share context. The applications can sharecontext in any suitable manner, as the aspects of the present inventiondescribed herein are not limited in this respect. For example, theapplications can include native context-sharing functionality tofacilitate sharing context in accordance with the CCOW standard (or anyother context-sharing protocol), or one or more of the softwareapplications cannot provide context-sharing functionality natively, butcan work in the computer system with a bridge or other component thatinterfaces with the application program and provides context-sharingfunctionality that enables the application program to share context withone or more other applications.

The above-described embodiments of the present invention can beimplemented in any of numerous ways. For example, the embodiments may beimplemented using hardware, software or a combination thereof. Forexample, one or more processors provided in a single computer ordistributed among multiple computers may be programmed using softwarecode to perform one or more aspects of the invention. It should beappreciated that any component or collection of components that performthe functions described above can be generically considered as one ormore controllers that control the above-discussed function. The one ormore controllers can be implemented in numerous ways, such as withdedicated hardware, or with general purpose hardware (e.g., one or moreprocessors) that is programmed using microcode or software to performthe functions recited above.

It should be appreciated that the various methods outlined herein may becoded as software which is executable on one or more processors thatemploy any one of a variety of operating systems or platforms.Additionally, such software may be written using any of a number ofsuitable programming languages and/or conventional programming orscripting tools, and also may be compiled as executable machine languagecode. In this respect, it should be appreciated that one embodiment ofthe invention is directed to a computer-readable medium (or multiplecomputer-readable media), such as computer memory, floppy disk(s),compact disk(s), optical disk(s), magnetic tape(s), and/or other media,which are encoded with one or more programs that, when executed on oneor more computers or other processors, perform methods that implementthe various embodiments of the invention discussed above. Thecomputer-readable medium or media can be transportable, such the programor programs stored thereon can be loaded onto one or more differentcomputers or other processors to implement various aspects of thepresent invention as discussed above.

It should be understood that the terms “application” and “program” and“software” are used herein in a generic sense to refer to any type ofcomputer code or set of instructions that can be employed to program acomputer or other processor to implement various aspects of the presentinvention as discussed above. Additionally, it should be appreciatedthat according to one aspect of this embodiment, one or more computerprograms that when executed perform methods of the present inventionneed not reside on a single computer or processor, but may bedistributed in a modular fashion amongst a number of different computersor processors to implement various aspects of the present invention.

Various aspects of the present invention may be implemented alone, incombination, or in a variety of arrangements not specifically describedin the foregoing. The present invention is therefore not limited in itsapplication to the details and arrangement of components set forth inthe foregoing description or illustrated in the drawings. The inventionis capable of other embodiments and of being practiced or of beingcarried out in various ways. Accordingly, the foregoing description anddrawings are by way of example only, and it is to be appreciated thatvarious alterations, modifications, and improvements will readily occurto those skilled in the art. Such alterations, modifications, andimprovements are intended to be part of this disclosure, and areintended to be within the spirit and scope of the invention.

Also, the phraseology and terminology used herein is for the purpose ofdescription and should not be regarded as limiting. The use of“including,” “comprising,” or “having,” “containing,” “involving,” andvariations thereof herein, is meant to encompass the items listedthereafter and equivalent thereof as well as additional items.

1. In a computer system comprising at least two software applicationssharing context in accordance with a Clinical Context Object Workgroup(CCOW) standard, wherein a context change may be requested by a user ofat least one of the at least two software applications, a methodcomprising acts of: (A) in response to the user requesting a change froma first context to a second context, applying at least one business ruleto at least a portion of the first context and/or to at least a portionof the second context to obtain at least one result from the applicationof the business rule; and (B) in response to the at least one result,performing at least one act selected from the group consisting of:denying the request to change from the first context to the secondcontext; requesting the user to provide information relating to therequested change; and requesting the user to affirm information relatingto the requested change.
 2. The method of claim 1, wherein the act (B)comprises, in response to the at least one result, performing the act ofdenying the request to change from the first context to the secondcontext.
 3. The method of claim 1, wherein the act (B) comprises, inresponse to the at least one result, performing the act of requestingthe user to provide information relating to the requested change.
 4. Themethod of claim 3, further comprising an act of: (C) in response to theuser providing the requested information relating to the requestedchange, storing the information.
 5. The method of claim 4, wherein thecomputer system further comprises an auditor capable of extractinginformation relating to user access to patient records, and wherein theact (C) comprises an act of storing the information in a data setaccessible to the auditor.
 6. The method of claim 4, further comprisingan act of: (D) auditing the information.
 7. The method of claim 3,wherein the second context relates to at least one patient, and whereinthe act (B) comprises, in response to the at least one result,requesting the user to provide information specifying a clinicalrelationship between the user and the at least one patient.
 8. Themethod of claim 1, wherein the act (B) comprises, in response to the atleast one result, performing the act of requesting the user to affirminformation relating to the requested change.
 9. The method of claim 8,further comprising an act of: (C) in response to the user affirming theinformation relating to the requested change, storing the information.10. The method of claim 9, wherein the computer system further comprisesan auditor capable of extracting information relating to user access topatient records, and wherein the act (C) comprises an act of storing theinformation in a data set accessible to the auditor.
 11. The method ofclaim 9, further comprising an act of: (D) auditing the information. 12.The method of claim 8, wherein the second context relates to at leastone patient, and wherein the act (B) comprises, in response to the atleast one result, requesting the user to affirm information specifying aclinical relationship between the user and the at least one patient. 13.The method of claim 1, wherein the act (A) comprises an act of applyingthe at least one business rule to at least a portion of the firstcontext to obtain the at least one result.
 14. The method of claim 1,wherein the act (A) comprises an act of applying the at least onebusiness rule to at least a portion of the second context to obtain theat least one result.
 15. The method of claim 1, wherein the act (A)comprises an act of applying the at least one business rule to at leasta portion of the first context and to at least a portion of the secondcontext to obtain the at least one result.
 16. The method of claim 1,wherein the computer system further comprises a context manager thatmanages context sharing between the at least two software applications.17. The method of claim 1, wherein the act (B) comprises, in response tothe at least one result, performing at least one act selected from thegroup consisting of: requesting the user to provide information relatingto the requested change; and requesting the user to affirm informationrelating to the requested change; and wherein the method furthercomprises an act of: (C) when the user fails to either provide or affirmthe requested information, performing an act of preventing the requestedcontext change from completing successfully.
 18. The method of claim 17,wherein the act (C) comprises an act of aborting the requested contextchange.
 19. The method of claim 17, wherein the act (C) comprises an actof compensating for any actions taken in an attempt to implement therequested context change.
 20. The method of claim 17, wherein the userinteracts with the at least two software applications via a userinterface, and wherein the act (B) comprises locking the user interfaceso that the user cannot gain access to at least some informationpresented by at least one of the at least two software applicationsuntil the user either provides or affirms the requested information. 21.The method of claim 1, wherein the act (B) comprises, in response to theat least one result, performing at least one act selected from the groupconsisting of: requesting the user to provide information relating tothe requested change; and requesting the user to affirm informationrelating to the requested change; and wherein the method furthercomprises an act of: (C) when the user provides or affirms the requestedinformation, performing an act of adding into the second context atleast some data based, at least in part, on the information provided oraffirmed by the user.
 22. The method of claim 21, wherein the act (C)comprises an act of adding into the second context the at least somedata based, at least in part, on the information provided or affirmed bythe user and the at least one business rule.
 23. The method of claim 21,wherein the act (C) comprises an act of adding the at least some datainto a subject in the second context that relates to user attempts toaccess patient records.
 24. The method of claim 1, wherein the secondcontext relates to at least one patient, and wherein the act (B)comprises, in response to the at least one result, performing the act ofrequesting the user to provide information specifying a clinicalrelationship between the user and the at least one patient.
 25. At leastone computer-readable medium encoded with instructions which, whenexecuted in a computer system comprising at least two softwareapplications sharing context in accordance with a Clinical ContextObject Workgroup (CCOW) standard, wherein a context change may berequested by a user of at least one of the at least two softwareapplications, perform a method comprising acts of: (A) in response tothe user requesting a change from a first context to a second context,applying at least one business rule to at least a portion of the firstcontext and/or to at least a portion of the second context to obtain atleast one result from the application of the business rule; and (B) inresponse to the at least one result, performing at least one actselected from the group consisting of: denying the request to changefrom the first context to the second context; requesting the user toprovide information relating to the requested change; and requesting theuser to affirm information relating to the requested change.
 26. The atleast one computer-readable medium of claim 25, wherein the act (B)comprises, in response to the at least one result, performing the act ofdenying the request to change from the first context to the secondcontext.
 27. The at least one computer-readable medium of claim 25,wherein the act (B) comprises, in response to the at least one result,performing the act of requesting the user to provide informationrelating to the requested change.
 28. The at least one computer-readablemedium of claim 27, further comprising an act of: (C) in response to theuser providing the requested information relating to the requestedchange, storing the information.
 29. The at least one computer-readablemedium of claim 28, wherein the computer system further comprises anauditor capable of extracting information relating to user access topatient records, and wherein the act (C) comprises an act of storing theinformation in a data set accessible to the auditor.
 30. The at leastone computer-readable medium of claim 28, further comprising an act of:(D) auditing the information.
 31. The at least one computer-readablemedium of claim 27, wherein the second context relates to at least onepatient, and wherein the act (B) comprises, in response to the at leastone result, requesting the user to provide information specifying aclinical relationship between the user and the at least one patient. 32.The at least one computer-readable medium of claim 25, wherein the act(B) comprises, in response to the at least one result, performing theact of requesting the user to affirm information relating to therequested change.
 33. The at least one computer-readable medium of claim32, further comprising an act of: (C) in response to the user affirmingthe information relating to the requested change, storing theinformation.
 34. The at least one computer-readable medium of claim 33,wherein the computer system further comprises an auditor capable ofextracting information relating to user access to patient records, andwherein the act (C) comprises an act of storing the information in adata set accessible to the auditor.
 35. The at least onecomputer-readable medium of claim 33, further comprising an act of: (D)auditing the information.
 36. The at least one computer-readable mediumof claim 32, wherein the second context relates to at least one patient,and wherein the act (B) comprises, in response to the at least oneresult, requesting the user to affirm information specifying a clinicalrelationship between the user and the at least one patient.
 37. The atleast one computer-readable medium of claim 25, wherein the act (A)comprises an act of applying the at least one business rule to at leasta portion of the first context to obtain the at least one result. 38.The at least one computer-readable medium of claim 25, wherein the act(A) comprises an act of applying the at least one business rule to atleast a portion of the second context to obtain the at least one result.39. The at least one computer-readable medium of claim 25, wherein theact (A) comprises an act of applying the at least one business rule toat least a portion of the first context and to at least a portion of thesecond context to obtain the at least one result.
 40. The at least onecomputer-readable medium of claim 25, wherein the computer systemfurther comprises a context manager that manages context sharing betweenthe at least two software applications.
 41. The at least onecomputer-readable medium of claim 25, wherein the act (B) comprises, inresponse to the at least one result, performing at least one actselected from the group consisting of: requesting the user to provideinformation relating to the requested change; and requesting the user toaffirm information relating to the requested change; and wherein themethod further comprises an act of: (C) when the user fails to eitherprovide or affirm the requested information, performing an act ofpreventing the requested context change from completing successfully.42. The at least one computer-readable medium of claim 41, wherein theact (C) comprises an act of aborting the requested context change. 43.The at least one computer-readable medium of claim 41, wherein the act(C) comprises an act of compensating for any actions taken in an attemptto implement the requested context change.
 44. The at least one computerreadable medium of claim 41, wherein the user interacts with the atleast two software applications via a user interface, and wherein theact (B) comprises locking the user interface so that the user cannotgain access to at least some information presented by at least one ofthe at least two software applications until the user either provides oraffirms the requested information.
 45. The at least onecomputer-readable medium of claim 25, wherein the act (B) comprises, inresponse to the at least one result, performing at least one actselected from the group consisting of: requesting the user to provideinformation relating to the requested change; and requesting the user toaffirm information relating to the requested change; and wherein themethod further comprises an act of: (C) when the user provides oraffirms the requested information, performing an act of adding into thesecond context at least some data based, at least in part, on theinformation provided or affirmed by the user.
 46. The at least onecomputer-readable medium of claim 45, wherein the act (C) comprises anact of adding into the second context the at least some data based, atleast in part, on the information provided or affirmed by the user andthe at least one business rule.
 47. The at least one computer-readablemedium of claim 45, wherein the act (C) comprises an act of adding theat least some data into a subject in the second context that relates touser attempts to access patient records.
 48. The at least onecomputer-readable medium of claim 25, wherein the second context relatesto at least one patient, and wherein the act (B) comprises, in responseto the at least one result, performing the act of requesting the user toprovide information specifying a clinical relationship between the userand the at least one patient.
 49. An agent for use in a computer systemcomprising at least two software applications sharing context inaccordance with a Clinical Context Object Workgroup (CCOW) standard,wherein a context change may be requested by a user of at least one ofthe at least two software applications, the agent comprising: at leastone processor programmed to, in response to the user requesting a changefrom a first context to a second context; apply at least one businessrule to at least a portion of the first context and/or to at least aportion of the second context to obtain at least one result from theapplication of the business rule; and in response to the at least oneresult, perform at least one act selected from the group consisting of:denying the request to change from the first context to the secondcontext; requesting the user to provide information relating to therequested change; and requesting the user to affirm information relatingto the requested change.
 50. The agent of claim 49, wherein the at leastone processor is programmed to, in response to the at least one result,perform the act of denying the request to change from the first contextto the second context.
 51. The agent of claim 49, wherein the at leastone processor is programmed to, in response to the at least one result,perform the act of requesting the user to provide information relatingto the requested change.
 52. The agent of claim 51, wherein the at leastone processor is programmed to, in response to the user providing therequested information relating to the requested change, store theinformation.
 53. The agent of claim 52, wherein the computer systemfurther comprises an auditor capable of extracting information relatingto user access to patient records, and wherein the at least oneprocessor is programmed to store the information in a data setaccessible to the auditor.
 54. The agent of claim 52, in combinationwith the computer system, wherein the computer system further comprises:an auditor that audits the information.
 55. The agent of claim 51,wherein the second context relates to at least one patient, and whereinthe at least one processor is programmed to, in response to the at leastone result, request the user to provide information specifying aclinical relationship between the user and the at least one patient. 56.The agent of claim 49, wherein the at least one processor is programmedto, in response to the at least one result, perform the act ofrequesting the user to affirm information relating to the requestedchange.
 57. The agent of claim 56, wherein the at least one processor isprogrammed to, in response to the user affirming the informationrelating to the requested change, store the information.
 58. The agentof claim 57, wherein the computer system further comprises an auditorcapable of extracting information relating to user access to patientrecords, and wherein the at least one processor is programmed to storethe information in a data set accessible to the auditor.
 59. The agentof claim 57, in combination with the computer system, wherein thecomputer system further comprises: an auditor that audits theinformation.
 60. The agent of claim 56, wherein the second contextrelates to at least one patient, and wherein the at least one processoris programmed to, in response to the at least one result, request theuser to affirm information specifying a clinical relationship betweenthe user and the at least one patient.
 61. The agent of claim 49,wherein the at least one processor is programmed to apply the at leastone business rule to at least a portion of the first context to obtainthe at least one result.
 62. The agent of claim 49, wherein the at leastone processor is programmed to apply the at least one business rule toat least a portion of the second context to obtain the at least oneresult.
 63. The agent of claim 49, wherein the at least one processor isprogrammed to apply the at least one business rule to at least a portionof the first context and to at least a portion of the second context toobtain the at least one result.
 64. The agent of claim 49, incombination with the computer system, wherein the computer systemfurther comprises a context manager that manages context sharing betweenthe at least two software applications.
 65. The agent of claim 49,wherein the at least one processor is programmed to, in response to theat least one result, perform at least one act selected from the groupconsisting of requesting the user to provide information relating to therequested change and requesting the user to affirm information relatingto the requested change; and wherein the at least one processor isfurther programmed to, when the user fails to either provide or affirmthe requested information, prevent the requested context change fromcompleting successfully.
 66. The agent of claim 65, wherein the at leastone processor is programmed to prevent the requested context change fromcompleting successfully by aborting the requested context change. 67.The agent of claim 65, wherein the at least one processor is programmedto prevent the requested context change from completing successfully bycompensating for any actions taken in an attempt to implement therequested context change.
 68. The agent of claim 65, wherein the userinteracts with the at least two software applications via a userinterface, and wherein the at least one processor is programmed to blockthe user interface so that the user is incapable of accessing at leastsome information presented by at least one of the at least two softwareapplications until the user either provides or affirms the requestedinformation.
 69. The agent of claim 49, wherein the at least oneprocessor is programmed to, in response to the at least one result,perform at least one act selected from the group consisting ofrequesting the user to provide information relating to the requestedchange and requesting the user to affirm information relating to therequested change; and wherein the at least one processor is furtherprogrammed to, when the user provides or affirms the requestedinformation, add into the second context at least some data based, atleast in part, on the information provided or affirmed by the user. 70.The agent of claim 69, wherein the at least one processor is programmedto, when the user provides or affirms the requested information, addinto the second context the at least some data based, at least in part,on the information provided or affirmed by the user and the at least onebusiness rule.
 71. The agent of claim 69, wherein the at least oneprocessor is programmed to add the at least some data into a subject inthe second context that relates to user attempts to access patientrecords.
 72. The agent of claim 49, wherein the second context relatesto at least one patient, and wherein the at least one processor isprogrammed to, in response to the at least one result, perform the actof requesting the user to provide information specifying a clinicalrelationship between the user and the at least one patient.
 73. Theagent of claim 49, wherein the computer system comprises a firstcomputer, wherein the at least two software applications each comprisesa user interface executing on the first computer, and wherein the atleast one processor comprises at least one processor on the firstcomputer programmed to provide a user interface for the agent on thefirst computer.
 74. The agent of claim 73, wherein the computer systemfurther comprises a second computer, and wherein the at least oneprocessor further comprises at least one processor on the secondcomputer that is programmed to perform at least some of thefunctionality of the agent and to communicate with the user interfacefor the agent.